Add all known outstanding yaml config options as of process-compose v1.7.3 #98
Conversation
…1.7.3
- per-process `description` that displays in the UI
- global and per-process `log_configuration`, including `rotation`
- global and per-process `vars` for supporting Go template expansion on configs
- `env_cmds` allows running host commands to populate env variables
- `ordered_shutdown` controls the order of process shutdown
- `is_strict` does additional checking on configuration files at startup
- `disable_env_expansion` to not propagate .env variables to processes
- `http_get.{headers,status_code}` and `working_dir` for probe commands
- `replicas` to run multiple copies of processes
- `entrypoint` alternate to `command`
- `is_elevated` for sudo/runas priviledged processes
- `extends,is_disabled,is_dotenv_disabled` for multi-file fragments and overrides.
- `launch_timeout_seconds` for daemon processes
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@shivaraj-bh Does this look good to be merged? |
|
|
||
| disable_env_expansion = mkOption { | ||
| type = types.nullOr types.bool; | ||
| default = null; |
There was a problem hiding this comment.
As discussed here setting this to true would be more appropriate and sane. It should be highlighted in the README\docs as it would diverge from PCs default
There was a problem hiding this comment.
should we also add all env vars from here to here:
process-compose-flake/nix/process-compose/cli.nix
Lines 18 to 27 in e968a94
There was a problem hiding this comment.
there are also some missing flags here, like disable-dotenv
There was a problem hiding this comment.
Why not inline this where the option is defined?
(Aside: I am not sure if this is even useful for nix-based configuration, IIUC let-bindings in nix make these redundant)
| extends = mkOption { | ||
| type = types.nullOr types.path; | ||
| default = null; | ||
| example = "process-compose.base.yaml"; | ||
| description = '' | ||
| Make the current configuration inherit all values in the given file. | ||
| See https://f1bonacc1.github.io/process-compose/merge#configuration-inheritance-with-extends | ||
| ''; | ||
| }; |
There was a problem hiding this comment.
This is redundant? Nix’s module system (by design) allows us to do this?
This and the vars comment makes me think: do we have to create options for every setting to replicate upstream? How about we make settings a freeform module? This should allow us to keep the API small (limited to what’s actually needed), while allowing users to still be able to set settings that are not defined.
There was a problem hiding this comment.
it's nice to have typed and documented options, although it increases maintenance burden
but what's annoying is not being able to easily configure stuff which has not been explicitly added yet, so maybe we could have extraEnvironment for na extraOptions (for flags) in which people could pass arbitrary untyped config? It would be similar to pattern use in nixos.
There was a problem hiding this comment.
regarding extends: might be useful for peoaple gradually migrating from multi-yaml configs, but we could warn in description that it's not advised when used with nix
descriptionthat displays in the UIlog_configuration, includingrotationvarsfor supporting Go template expansion on configsenv_cmdsallows running host commands to populate env variablesordered_shutdowncontrols the order of process shutdownis_strictdoes additional checking on configuration files at startupdisable_env_expansionto not propagate .env variables to processeshttp_get.{headers,status_code}andworking_dirfor probe commandsreplicasto run multiple copies of processesentrypointalternate tocommandis_elevatedfor sudo/runas priviledged processesextends,is_disabled,is_dotenv_disabledfor multi-file fragments and overrides.launch_timeout_secondsfor daemon processes